21章 コラボレーティブコンストラクション

コラボレーティブコンストラクションテクニックは、エラーを明らかにするために誰かに自分のコードを見てもらうプロセスを形式化したもの

ペパボがどんな感じなのか知りたい

インスペクション…コードやドキュメントについての目視での検査のこと。インスペクション、レビュー、ウォークスルーの順にカジュアルとのこと

21.1 コラボレーティブ開発プラクティスの概要

「コラボレーティブコンストラクション」とは、ペアプログラミング、公式なインスペクション、非公式なテクニカルレビュー、ドキュメントリーディングなど、コードの作成や他の作業の結果に対する責任を開発者が共有するためのテクニックを意味する。

コードに問題があっても当事者には見えないことがある。このような盲点は人によって異なるので、だれかに自分のコードを見てもらうことは開発者にとって有益である

21.1.1 コラボレーティブコンストラクションによる品質保証テクニックの補完

コラボレーティブコンストラクションの第一目標はソフトウェアの品質を改善すること

平均的な欠陥検出率

単体テスト：30%

統合テスト：35%

小規模なベータテスト：35%

設計：55%

コードインスペクション：60%

ペアプログラミングに関する報告

ペアプログラミングの品質はコードインスペクションと同等

コストは1人あたりの10~25%上回るが、開発時間は45%も短縮できる

IBMは、1時間のインスペクションで約100時間分の関連作業（テストと欠陥修正）を回避できることをつきとめた

Raytheonは、インスペクションに焦点を合わせたイニシアチブによって、作業のやりなおしのコストを総費用の40%から20%に削減した

自社のインスペクションプログラムが2150万ドル(1994)の支出削減に

約400個のプログラムを管理するコストが、インスペクションが済んでいない同様のプログラム群を管理するコストの10%にも満たない

多くのプログラムを調査した結果、インスペクションに1時間を費やすごとに平均33時間の保守作業を回避することができ、インスペクションが最大でテストの20倍も効率的であることがわかった

コードレビューによって、1行変更の原因は55%がエラーだったが、2%まで減った

インスペクションによって、エラーが80%以上も減った

人がレビューすれば、わかりにくいエラーメッセージ、不十分なコメント、ハードコーディングされた定数値、1つにまとめるべき同じコードパターンの繰り返しを見抜くことができる、しかし、テストではそうはいかない

21.1.2 コラボレーティブコンストラクションによる企業文化とプログラミング技術の指導

ソフトウェアの開発規則は、浸透させる努力をしなければ誰も従わない

未熟なプログラマは、よりベテランのプログラマの指導がなければ、ノウハウを知る機会がない

レビューやインスペクションを行うことで、これらの機会を設けることができる

21.1.3 すべてのコラボレーティブコンストラクションに適用される共同所有

コードを共有して、作業者が閲覧・編集できるようにするとよいという話

GitやSVNが浸透してないときの話かな？

詳細は28章の「28.2 構成管理」で

21.1.4 コンストラクション前後のコラボレーション

参考資料を見てね

21.2 ペアプログラミング

ペアプログラミングはそもそもXPによって一般に知られるようになったものだが（Beck2000）、今では広く利用されるようになった（WilliamsandKessler2002）。

21.2.1 ペアプログラミング成功の鍵

コーディング標準でペアプログラミングをサポートする

本質的でないところで議論が起きないように、事前に規約を作っておく

ペアプロをただの監視にしない

コードを書かないプログラマもプログラミングに積極的に参加するべき

コードの分析、設計の評価、コードのテスト計画を考える等

ペアプロを安易に使用しない

ホワイトボードで詳細設計を確認してから、1人でコードを書いた方がいい場合もある

ペアプロを試した組織のほとんどは、作業の一部にペアプロを導入している

ペアと作業の割り当てを定期的に交代する

ペアを定期的に交代することで知的な交流を促す

パートナーのペースを合わせる

両方のパートナーが画面を見れるようにする

仲の悪い人を組ませない

初心者同士を組ませない

チームリーダーを割り当てる

21.2.2 ペアプログラミングの利点

1人で開発するよりもストレスに強い

品質の高いコードを書くようになる

コードの品質が向上する

読みやすさと理解しやすさ、チームのエース級になる

スケジュールが短縮される

コーディングの時間が短く、エラー量が減る傾向にある

コラボレーティブコンストラクションの一般的な利点

企業文化の改善、若手プログラマの育成、共同所有の促進

JetBrainsの時にはコード共有にこれを使った気がする

21.3 公式なインスペクション

インスペクションは、欠陥の検出に優れ、テストに比べてコストが低い

インスペクションとレビューの違い

チェックリストは、過去に問題となった領域にレビューアの注意を向けさせる。

インスペクションは、欠陥の修正ではなく欠陥の検出に重点を置く。

レビューアは、インスペクションミーティングに備えて準備を行い、発見された問題をリストにまとめてミーティングに向かう。

すべての参加者に明確な役割が与えられる。

インスペクションのモデレータ（進行役）は、インスペクションの対象となる案件の作成者ではない。

モデレータはインスペクションの進行に関して特別な訓練を受けている。

インスペクションミーティングは、すべての参加者の準備が十分に整った時点で、はじめて開かれる。

毎回のインスペクションでデータが収集され、将来のインスペクションの改善に役立てられる。

プロジェクト計画などの管理資料がインスペクションの対象となる場合を除き、経営陣はインスペクションミーティングに参加しない。テクニカルリーダーは出席してもよい。

21.3.1 インスペクションから期待できる効果

1回のインスペクションで60%の欠陥が検出される

設計のインスペクションとコードのインスペクションを組み合わせると、70~85%の欠陥が取り除かれる

インスペクションはプロジェクトの進捗を評価するためにも利用できる

21.3.2 インスペクションにおける役割

モデレータ

十分な速さでなおかつできるだけ多くのエラーを検出できる時間をかけて、インスペクションを進行させる責任をもつ

インスペクションの対象となる設計やコードの専門家である必要はないが、関連情報を理解できる必要がある

その他インスペクションに必要な雑務は何でも行う

作成者

設計やコードの作成者はインスペクションでは脇役に徹する

インスペクション対象の設計やコードで不明瞭な点があれば、作成者は速やかにそれを明確にする

レビューア

設計やコードの当事者であるが、作成者ではない人

開発メンバーくらいのニュアンス

レビューアの役目は欠陥を発見すること

記録係

作成者やモデレータが兼任しないこと

経営陣

原則として参加しない

インスペクションは技術的なレビューである

インスペクションの結果を査定に利用するべきではない

21.3.3 インスペクションの基本手順

計画

よくある会議の計画と同じ

概要説明

必要に応じて技術環境を説明する場を設ける

設計やコードの言い訳の場にならないように注意する

準備

設計やコードのエラーを予め洗い出しておく

特定の立場(保守プログラマ, 顧客, 設計者)の目線でチェックをするとエラーの検出率が上がる

高級言語で書かれたアプリケーションのコードレビューでは、レビューアは1時間に約500行のコードの準備を済ませることができる。しかし、高級言語で書かれたシステムのコードレビューでは、1時間に約125行のコードの準備をするのがやっとである（Humphrey1989）

ミーティング

作成者以外の人物に設計の説明やコードの説明をさせる

エラーに関する議論は、それがエラーだと認識された時点で終了させる

ミーティングでは解決策を話し合うことはせずに、あくまでもエラーの検出にこだわる

ミーティングに2時間以上はかけない

インスペクションレポート

ミーティングが行われた日のうちに、エラーのレポートを作成する

レポートを活用することで、インスペクションに関する疑いを解消できる

修正

基本的には作成者が担当

フォローアップ

モデレータはインスペクションで発生したエラーの修正の対応完了を確認する責任がある

3時間目のミーティング

インスペクション後に関係者のみのミーティングを行っても良い

インスペクションの微調整

調整をかけるまえに効果測定が出来るようにする必要がある

あまりやり方はかえないように

21.3.4 インスペクションにおけるエゴ

設計やコードの作成者を非難することは決してあってはならない

21.3.5 インスペクションの実例

Code Completeでもインスペクションを実施した模様

21.3.6 インスペクションのまとめ

インスペクションの効果は明確なチェックリストと役割分担に依存する

フィードバックを繰り返すことで、チェックリストが改善され準備やインスペクションの中身が最適化される

21.4 その他のコラボレーティブ開発プラクティス

21.4.1 ウォークスルー

ほぼ全てのレビューがウォークスルーに該当する

司会進行は、設計やコードの作成者が行う

ウォークスルーは30~60分くらいかけて行われる

インスペクションに比べると役割分担が柔軟な分、選択しやすい

21.4.2 コードリーディング

ウォークスルーとの違いは、会議よりもコードの個々のレビューに重点をおいていること

ミーティング自体の時間は短く済むため、地理的に離れている状況でも選択しやすい

21.4.3 ドッグアンドポニーショー

顧客へソフトウェアをデモンストレーションすること

プロジェクトが円滑に進んでいることを見せるのが目的で、技術的ではなく経営的なレビューになる

21.5 コラボレーティブコンストラクションテクニックの比較

https://gyazo.com/d287a11d67a07e7c0db1c09c8b87ed3c

https://gyazo.com/53b27c4f37ba31123b9424771349652c

21.6 参考資料

21.7 まとめ

コラボレーティブ開発プラクティスは、テストよりも高い割合で、より効果的に欠陥を検出する傾向がある

コラボレーティブ開発プラクティスは、テストとは異なる種類のエラーを検出する傾向がある

ソフトウェアの品質を保証するためには、レビューとテストの両方を使用する必要がある

公式なインスペクションでは、エラーをできるだけ効率よく検出するために、チェックリスト、準備、明確な役割、継続的なプロセス改善が必要である

インスペクションでは、一般にウォークスルーよりも多くの欠陥が検出される

ペアプログラミングは一般にインスペクションと同じ程度のコストがかかり、同じような品質のコードを生み出す

ペアプログラミングはスケジュールの短縮が望まれるときに威力を発揮する

1人で作業するよりも、ペアで作業することを好む開発者もいる

公式なインスペクションは、コードだけでなく、要求、設計、テストケースなどの作業にも利用できる

ウォークスルーとコードリーディングはインスペクションの代替手段である

コードリーディングは、参加者の時間を効率よく使用する点で、柔軟性に優れている